Several open issues are caused by the multipart/form-data formatter trying to provide a simple API based on an input of type Object. However, Object can not express some of the typical use cases of a multipart request. On the other hand, FormData could.

One example (mentioned in #705 and #965) is sending a requested with multiple entries belonging to the same "key". Since a FormData object allows one key to be mapped to multiple values, one can simply do:

f = new FormData()
f.append('files', new Blob())
f.append('files', new Blob())
[...f.keys()] // This gives 2 entries, as expected

This is clearly not possible with an Object, where the key-value relationship is 1:1. #1000 tries to achieve this by automatically converting Array values to multiple FormData keys. However, I argue that it is not necessarily what the user wants, since they could either expect:

• that the array is sent as-is as a single FormData entry, or
• that each array is sent a separate FormData entries.

In principle, it is not so easy to infer which of the two is the one desired by the user.

Currently, however, inputs of type FormData are not correctly handled by the multipart/form-data formatter for the Fetch client, which tries to enumerate the keys using the Object.keys(...) construct:

Unfortunately, FormData returns an empty list when used through Object.keys()

f = new FormData()
f.append('files', new Blob())
f.append('files', new Blob())
Object.keys(f) // This gives an empty array!

This PR proposes a way to allow the user to directly supply a FormData, basically opting out of any smart formatting logic that might actually get in the way. In this way, the user takes responsibility for correctly managing the conversion.

I argue that the breaking change is minimal since any use of FormData is broken under the current API. Additionally, this would align with the logic for the Axios client, which already short-circuits the formatting for FormData inputs.